Amazon Lookout for Metricsに再入門する
はじめに
こんちには。
データアナリティクス事業本部 機械学習チームの中村です。
2022年のアドベントカレンダーをきっかけに始めた、AWSのフルマネージドな機械学習サービスの再入門の続報です。
本記事ではAmazon Lookout for Metricsに入門していきます。
Amazon Lookout for Metricsとは
Amazon Lookout for Metricsはデータの異常を発見し、その根本原因を突き止め、迅速に対策を講じることを可能にするサービスです。
Amazon.comで使用されている技術と同じもので構築され、異常検知と機械学習における20年の専門知識が反映されています。公式ブログによれば長期トレンドや季節性も考慮した上で、異常を検出するように動作するようです。
概要は以下のとおりです。
- データソースを使用して検出器を構成し監視する値(メジャー)を選択
- 監視する値は別のデータ(ディメンション)によるグループ化も可能
- 検出器はデータソースから学習し、学習には数時間から数日間のデータを使用(後述の異常を検出する頻度に依存)
- 異常を検出する頻度は、5分から1日の間で選択可能
- 実際にその期間実時間でデータをインポートする必要はなく、期間分の履歴データがあればよい
- 履歴データを使う場合、バックテストモードで評価することも可能
- 異常を発見した場合、重大度スコアも得ることができる
- 重大度の高い異常が発生した場合アラートを送信でき、Lambda関数の実行やSNSトピックへの通知が可能
- データソースとしてはAthena, S3, CloudWatch, RDS, Redshift, AppFlow経由でのソースに対応(正式名称は略記)
公式ドキュメントは以下となります。
Pricing(料金)
使用する前にPricingを確認していきましょう。
(Pricingを確認することでおおよその機能概要も把握できます)
純粋に監視する値(メジャー)の点数分の費用がかかる形となっているようです。
また元となる監視する値が1つであっても、ディメンションが多ければ多いほどその分監視する値の数も増加するので、そこは意識しておく必要があります。
公式の例:売り上げ上位100つ、50の地域で収益と注文数を監視する場合
- 2つの指標(収益、注文数)×100製品×50地域=10,000 ($4,000 per month)
検出器の学習や検出する頻度は、Pricingに影響してこない点はポイントです。
とはいえ検出器を構成した段階で最小単価(例えば$0.75)は費用が発生するので意識しておく必要があります。
実際に試してみた
試してみるにあたって、AWS公式ブログの以下の記事を参考にしました。
S3へデータを準備
コンソールからS3バケットを作成しておきます。今回はcm-nakamurashogo-sample-lookout-for-metrics
というバケットを作成したとして進めます。
そこに以下のcsvファイルをアップロードしていきます。
データは以下のようになっています。
TIMESTAMP,LOCATION_ID,EARNED_POINTS,REDEEM_POINTS 2021-01-01,A-1001,26208,33377 2021-01-01,A-1002,21826,28812 2021-01-01,A-1003,28890,20209 2021-01-01,A-1004,23272,30617 2021-01-01,A-1005,23997,28285 2021-01-01,A-1006,26812,33534 2021-01-01,A-1007,34539,29419 2021-01-01,A-1008,24885,29440 2021-01-02,A-1001,28950,34435 2021-01-02,A-1002,26874,29739 2021-01-02,A-1003,34380,30008 2021-01-02,A-1004,33620,29857 2021-01-02,A-1005,27154,30781 2021-01-02,A-1006,25531,32980 2021-01-02,A-1007,27647,25660 ...
LOCATION_IDをA-1001に限定すると、全体像は以下のようなデータになります。
EARNED_POINTSが獲得したポイント数、REDEEM_POINTSが交換したポイント数となっており、その異常検知用のデータとなっているようです。
LOCATION_IDが8種類あり、それぞれデイリーでの値が2021-01-01から2022-09-30の期間で格納されています。
Detectorの作成
「Create detector」を押下して検出器を作成します。
Detector Detailsを以下のように設定します。
他はデフォルトのままで「Create」を押下します。
Datasetの作成
Choose a datasource
以下の「Add a dataset」を押下します。
Basic informationは以下のように設定します。
Datasource detailsを以下のように設定します。
DatasourceはAmazon S3とし、Detector modeはBacktestを選択しました。
サービスロールは新規に作成しました。
上記の画面で「Detect format settings」を押下すると、「Historical data」にあらかじめ置いてあるデータから、自動的にフォーマットを設定してくれます。
こちらで自動フォーマット認識されない場合、S3にデータが置いてあるかご確認ください。
フォーマットの内容が問題なければ「Next」を押下します。ここでしばらくロード画面となります。
Map fields
MeasuresとDimensionsを以下のように設定します。
Field nameにEARNED_POINTSとREDEEM_POINTSの2種類を指定し、Aggregate byはSUMとしました。
Dimensionsには、LOCATION_IDを指定します。
Aggregate byは、例えば今回のようなデータのケースでは、もしDimensionsを指定しなかった場合に、同一時間点に複数の値が出現するため、それをどのように集約するのかを決める方法になります。SUMとAVGを選択できます。
Dimensionsが特に無いようなデータセットで、同一時間点に単一の値しか存在しない場合は、SUMでもAVGでもどちらも同じ値となります。
MeasuresとDimensionsの個数は、マネジメントコンソールを見る限り、Measuresは1~10個、Dimensionsは0~10個設定できそうです。
Dimension filterというものもあります。公式の説明文を以下に添えます。
特定のディメンション値に基づいてデータをフィルタリングするために使用されます。たとえば、特定の地域の異常の検出にのみ関心がある場合、ディメンションフィルターを使用して、どの地域に関心があるかを指定できます。 フィルタを定義すると、異常検出に使用されるデータに対してのみ課金されるため、コストを削減し、推論とトレーニングの時間を短縮することができます。
通常は、あるDimensionの特定の値に限定して分析するために使用されるようですね。今回はここで3つの条件に絞って料金を抑えながら検証をしてみます。
Timestampは以下のように設定します。
Cost Estimateを計算することができます。Dimensionのユニーク数に依存しますので、ユーザが自身で入力すればコスト推定値を得ることができます。
今回はDimension filterで3つに絞ったので3を入力しておきます。
「Next」を押下すると最終確認画面になります。
ここで「Save dataset」と「Save and activate」を選択でき、Activateすると料金が発生しまじめます。
「Save and activate」を押下します。すると以下のようなメッセージがでます。
Your detector uses continuous data. Once the detector is active, it uses data from several intervals to learn before finding anomalies. While it learns, you can configure alerts. You begin incurring costs when you activate the detector. Your costs are based on the number of metrics that Lookout for Metrics monitors for anomalies and potential causes. A metric is a combination of a measure, a dimension and it’s value. Learn more
To confirm you understand the costs, type “confirm” in the field.
ここで問題なければ「confirm」を入力します(ここから料金が発生し始めます)。
すると、Detectorが以下のように「Activating backtest...」となります。
完了すると、「Backtest complete」となり、「View anomalies」から結果を確認できます。
結果の確認
「View anomalies」を押下すると、以下のようにREDEEM_POINTS(交換したポイント数)で異常が発生している旨が表示されています。
Severity scoreは重大度スコアであり、0から100の間の数値で指標値が期待される範囲からどの程度外れているかを示します。
Severity scoreが高ければ高いほど、その異常はより予期しないものとなります。
閾値もこの画面で調整できるようになっており、アラートを送る基準を設定できそうです。
検出された異常の行をクリックすると、「Metric graphs」などの波形も確認することができます。
その他本記事で触れれなかったこと
BacktestモードではなくConinuousモードにすることで、S3のデータを自動的に取り込みながら異常検出を実行することができます。
あらかじめ決められたインターバルでS3にデータが置かれることを期待されるので、その点はご注意ください。
まとめ
いかがでしたでしょうか。Amazon Lookout for Metricsについての一通りの使用方法について触れていきました。
本記事が、今後Amazon Lookout for Metricsを活用されようとする方の一助となれば幸いです。